SPECIFICATION 



To all whom it may concern: 

Be it known that I, I LAN GABRIEL CARON, a citizen of 
the United States, residing at 1265 23RD AVENUE EAST, 
SEATTLE, WASHINGTON 98112 has invented a certain new and 
useful METHOD AND APPARATUS FOR CREATING, SENDING, AND 
USING SELF-DESCRIPTIVE OBJECTS AS MESSAGES OVER A MESSAGE 
QUEUING NETWORK, of which the following is a 
specification - 
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AS MESSAGES OVER A MESSAGE QUEUING NETWORK 



FIELD OF THE INVENTION 

This invention relates to computer programming and 
networking, and more particularly to an automated 
method and computer apparatus for sending and using 
self-descriptive objects as messages over a message 
queuing network. 

BACKGROUND OF THE INVENTION 

Users and developers of networked applications and 
systems desire reliable, faster and easier to use 
methods of communicating information between source and 
destination computer applications and operating 
environments. Traditional messaging techniques require 
each application to know the specific serialized format 
of a message, or require communication between the 
operating environments of the sender and receiver to 
provide information or meta-data so that the receiver 
can interpret the message. Computer users and 
applications developers are desirous of new methods and 
computer apparatus for communicating messages which 
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decrease the amount of configuration and runtime 
overhead involved . 

Most distributed computing applications today use 
synchronous communication technologies, such as remote 
5 procedure calls. Such synchronous communications 

require a sender of a request to wait for a response 
from the receiver of the request before it can proceed 
and perform other tasks. The time that the sender must 
wait depends on the time it takes for the receiver to 

10 process the request and return a response. Synchronous 
communication mechanisms also require the sender and 
the receiver to be operating simultaneously. 

In contrast, using asynchronous communications, 
senders make requests to receivers and can move on to 

15 perform other tasks immediately. If a response is 
expected back from the receiver, it is up to the 
original sender to decide when it will actually look 
for and process the response. Most importantly, there 
is no guarantee that receivers will process requests 

20 within any particular period of time. In fact, with 

asynchronous communications, there are no requirements 
that receivers be running nor even the communications 
infrastructure be available in order for a sender to 
initiate a request. 
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Message queuing systems implement asynchronous 
communications by enabling applications to send 
messages to and receive messages from other 
applications. These applications may be running on the 
5 same machine or on separate machines connected by a 
network. When an application receives a request 
message, it processes the request by reading the 
contents of the message formatted in a known pattern 

ill and acting accordingly. If required, the receiving 

i a * 10 application can send a response message back to the 
original requestor. 

^ Many applications are now using message queuing 

networks for the enhanced communication delivery 

jff reliability between networked computer systems provided 

;j3 15 by sending messages asynchronously across a message 

yd 

queuing enterprise network. However, these messages 
are simply received as type-less buffers of raw data 
that are passed between applications. In some 
instances, these messages have additional signaling 
20 information attached that describe how the message 

should be sent by the underlying sub-system. However, 
the messages do not provide any semantic information 
that enables the message recipient to interpret the 
meaning of the message contents. To communicate, the 



source and destination applications rely either on 
private message content encoding schemes or prior 
arrangements between the applications to only send 
messages of a certain type. 

SUMMARY OF THE INVENTION 

According to the invention, an automated method 
and apparatus are provided for creating, sending, and 
using self-descriptive objects as messages between 
applications, and additionally sending these message 
objects over a message queuing network. Required 
meta-inf ormation is included with these 
self-descriptive messages making them self-contained 
and requiring no external components to interpret them. 
Using the present invention, networked applications can 
communicate arbitrary objects in a standard way with no 
prior agreement as to the nature and semantics of 
message contents. In this manner, applications are 
more robust and can readily adapt to changes to message 
contents without having to update the format or 
structure of the message, or to update the application 
to interpret the encoded body of a new message format. 

In one embodiment of the present invention, 
messages are sent as serialized dictionary objects over 



a message queuing network. The dictionary represents 
an abstract data type defined in terms of four 
fundamental operations that can be performed on it, 
namely: add, remove, lookup, and enumerate. These 
operations correspond to methods invoked to perform the 
desired operation- As implied by the method names, 
add ( ) adds a specified element to the dictionary; 
remove ( ) removes a specified element in the dictionary; 
lookup () finds a specified element in the dictionary; 
and enumerate () returns one element from the 
dictionary, allowing the retrieval of all elements from 
the dictionary. 

The dictionary elements, in an embodiment of the 
present invention, are in the form of a triplet 
comprised of a Name, Type and Value. The Name 
represents a string identifier; the Type specifies the 
type of element which could be as simple as a constant 
or integer, or be a more complex (and very rich) type 
such as an Excel spreadsheet or even another serialized 
data dictionary; and the Value specifies a current 
value or state of the element. The previously 
described triplet merely illustrates a very generalized 
abstract data element. Various other dictionary data 
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elements could be employed in keeping with the present 
invention . 

To enable the dictionary object to be sent across 
a network, the dictionary object is able to serialize 
5 and deserialize itself using two more of its methods. 
The save ( ) method causes the dictionary object to 
serialize itself to the body of a message, and the 
load() method loads into the object a previously 
serialized dictionary object located in the body of a 

10 received message. 

In accordance with the present invention, a sender 
application creates a persistent dictionary object, and 
populates the object with the desired contents of the 
message. The sender application then requests the 

15 dictionary object to save or serialize itself into the 
body of a message queuing message (or the dictionary 
object could be serialized into a buffer which is 
copied or moved into the body of a message queuing 
message prior to sending the message) . The message 

20 queuing system forwards the message containing the 
serialized object to the destination queue. 

Upon receipt from the destination queue, the 
receiving message queuing system looks at the received 
message, and determines that it contains a dictionary 



object in the body of the message. The destination 
message queuing system then instantiates and loads the 
message object with the data dictionary, and passes the 
object to the recipient application. 

The recipient application then uses the dictionary 
object in any manner it chooses. In one embodiment of 
a recipient application, the recipient application 
enumerates the elements of the data dictionary and 
takes appropriate programming action for each element 
according to its type. For example, a received Excel 
spreadsheet in a dictionary element could cause the 
application to start an Excel application and to 
forward the value of the element (i.e., the Excel 
spreadsheet) to the Excel application. Other 
dictionary elements might contain a single integer, or 
records containing multiple fields which would be 
processed accordingly by the recipient application. 
Thus, the present invention provides a generalized and 
robust messaging mechanism whereby the sending and 
receiving applications no longer rely on a previous 
agreed to protocol format or a specialized 
serialization scheme . 



BRIEF DESCRIPTION OF THE DRAWINGS 



The appended claims set forth the features of the 
present invention with particularity. The invention, 
together with its advantages and as previously 
described, may be better understood from the following 
detailed description taken in conjunction with the 
accompanying drawings of which: 

FIG. 1A is a block diagram of an exemplary 
operating environment in which the invention may be 
implemented, including a computer network comprising 
computer systems for sending and using self-descriptive 
objects as messages over a message queuing network in 
accordance with the invention; 

FIG. 2A is a block diagram illustrating the 
transmission of messages in a message queuing 
environment ; 

FIG. 2B is a block diagram illustrating sites 
within a message queuing environment; 

FIG. 2C is a block diagram illustrating connected 
networks within a message queuing environment; 

FIG. 3A is a block diagram illustrating the an 
embodiment of a persistent dictionary object with its 
interfaces and methods; 
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FIG- 3B is a block diagram illustrating an 
exemplary format of the serialized dictionary object; 

FIG- 4A is a flow diagram illustrating the steps 
performed by an application to send a message object; 
5 FIG. 4B is a flow diagram illustrating the steps 

performed by an application using a received message 
object ; 

FIG. 5A is a flow diagram illustrating the steps 
performed by a MSMQ server to serialize and send a 
10 message object; and 



Vi FIG. 5B is a flow diagram illustrating the steps 

W 

taken by a MSMQ server in response to receiving a 
I*: serialized message object. 

t :' : 
s . s 

!f3 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

15 FIG. 1 and the following discussion are intended 

to provide a brief, general description of a suitable 
computing environment in which the invention may be 
implemented. Although not reguired, the invention will 
be described in the general context of 

20 computer-executable instructions, such as program 
modules, being executed by a personal computer. 
Generally, program modules include routines, programs, 
objects, components, data structures, etc. that perform 
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particular tasks or implement particular abstract data 
types. Moreover, those skilled in the art will 
appreciate that the invention may be practiced with 
other computer system configurations, including 
5 hand-held devices, multiprocessor systems, 

microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may also be 
practiced in distributed computing environments where 
10 tasks are performed by remote processing devices that 
are linked through a communications network. In a 
distributed computing environment, program modules may 
be located in both local and remote memory storage 
devices . 

15 With reference to FIG. 1, an exemplary system for 

implementing the invention includes a general purpose 
computing device in the form of a conventional personal 
computer 20, including a processing unit 21, a system 
memory 22, and a system bus 23 that couples various 

20 system components including the system memory to the 
processing unit 21. The system bus 2 3 may be any of 
several types of bus structures including a memory bus 
or memory controller, a peripheral bus, and a local bus 
using any of a variety of bus architectures. The 



system memory includes read only memory (ROM) 24 and 
random access memory (RAM) 25. A basic input/output 
system 26 (BIOS) containing the basic routines that 
helps to transfer information between elements within 
the personal computer 20, such as during start-up, is 
stored in ROM 24. In one embodiment of the present 
invention on a server computer 20 with a remote client 
computer 49, commands are stored in system memory 22 
and are executed by processing unit 21 for creating, 
sending, and using self-descriptive objects as messages 
over a message queuing network in accordance with the 
invention. The personal computer 20 further includes a 
hard disk drive 27 for reading from and writing to a 
hard disk, not shown, a magnetic disk drive 28 for 
reading from or writing to a removable magnetic disk 
29, and an optical disk drive 30 for reading from or 
writing to a removable optical disk 31 such as a CD ROM 
or other optical media. The hard disk drive 27, 
magnetic disk drive 28, and optical disk drive 30 are 
connected to the system bus 23 by a hard disk drive 
interface 32, a magnetic disk drive interface 33, and 
an optical drive interface 34, respectively. The 
drives and their associated computer-readable media 
provide nonvolatile storage of computer readable 
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instructions, data structures, program modules and 
other data for the personal computer 20. Although the 
exemplary environment described herein employs a hard 
disk, a removable magnetic disk 29 and a removable 
optical disk 31, it should be appreciated by those 
skilled in the art that other types of computer 
readable media which can store data that is accessible 
by a computer, such as magnetic cassettes, flash memory 
cards, digital video disks, Bernoulli cartridges, 
random access memories (RAMs) , read only memories 
(ROM) , and the like, may also be used in the exemplary 
operating environment . 

A number of program modules may be stored on the 
hard disk, magnetic disk 29, optical disk 31, ROM 24 or 
RAM 25, including an operating system 35, one or more 
application programs 36, other program modules 37, and 
program data 38. A user may enter commands and 
information into the personal computer 20 through input 
devices such as a keyboard 40 and pointing device 42. 
Other input devices (not shown) may include a 
microphone, joystick, game pad, satellite dish, 
scanner, or the like. These and other input devices 
are often connected to the processing unit 21 through a 
serial port interface 46 that is coupled to the system 
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bus, but may be collected by other interfaces, such as 
a parallel port, game port or a universal serial bus 
(USB) . A monitor 47 or other type of display device is 
also connected to the system bus 23 via an interface, 
5 such as a video adapter 48. In addition to the 

monitor, personal computers typically include other 
peripheral output devices (not shown) , such as speakers 
and printers. 

The personal computer 20 may operate in a 

10 networked environment using logical connections to one 
or more remote computers, such as a remote computer 49. 

The remote computer 4 9 may be another personal 
computer, a server, a router, a network PC, a peer 
device or other common network node, and typically 

15 includes many or all of the elements described above 
relative to the personal computer 20, although only a 
memory storage device 50 has been illustrated in 
FIG. 1. The logical connections depicted in FIG. 1 
include a local area network (LAN) 51 and a wide area 

20 network (WAN) 52. Such networking environments are 
commonplace in offices, enterprise-wide computer 
networks, intranets and the Internet. 

When used in a LAN networking environment, the 
personal computer 20 is connected to the local network 
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51 through a network interface or adapter 53. When 
used in a WAN networking environment, the personal 
computer 20 typically includes a modem 54 or other 
means for establishing communications over the wide 
5 area network 52, such as the Internet. The modem 54, 
which may be internal or external, is connected to the 
system bus 23 via the serial port interface 46. In a 
networked environment, program modules depicted 
relative to the personal computer 20, or portions 

10 thereof, may be stored in the remote memory storage 
device. It will be appreciated that the network 
connections shown are exemplary and other means of 
establishing a communications link between the 
computers may be used. 

15 The present invention provides for sending 

self-descriptive message objects as messages between 
two or more applications, and operates in any computing 
environment that supports data objects, whether on a 
standalone computer or preferably in a networked 

20 environment. Using self-descriptive objects as 

messages, a recipient no longer relies on a convention 
or a special-coding serialization scheme. The 
recipient application can simply extract a data element 
from the received object in a standard, well-known way, 
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discover the element's logical type, and take 
appropriate programmatic action. 

The present invention is described in the context 
of a Microsoft Message Queue Server (MSMQ) network and 
5 using Microsoft Component Object Model (COM) objects in 
order to illustrate one embodiment of the invention. 
The present invention is not so limited, as the 
teachings disclosed herein provide for the present 
invention to be used in other messaging systems and 

10 communications networks, as well as using other forms 
of objects and self-descriptive structures. 

A brief introduction of JH^ssage queuing is 
provided below. A more derailed explanation of MSMQ is 
described in "Microsoft Message Queue Server (MSMQ) , " 

15 MSDN Library - 1 Apml 1998, Microsoft Corporation, and 
is hereby incom0rated by reference. And a detailed 
explanation/of COM is described in described in "COM 
and ActiveX Object Services," MSDN Library - 
April/1998, Microsoft Corporation, and is hereby 

20 incorporated by reference. 

MSMQ implements asynchronous communications by 
enabling applications to send messages to, and receive 
messages from, other applications. These applications 
may be running on the same machine or on separate 
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machines connected by a network, MSMQ messages can 
contain data in any format that is understood by both 
the sender and the receiver. When an application 
receives a request message, it processes the request by 
5 reading the contents of the message and acting 

accordingly. If required, the receiving application can 
send a response message back to the original requestor. 

While in transit between senders and receivers, 
MSMQ keeps messages in holding areas called queues, 

10 hence the name message queuing. MSMQ queues protect 

messages from being lost in transit and provide a place 
for receivers to look for messages when they are ready. 
Applications make requests by sending messages to 
queues associated with the intended receiver. If 

15 senders expect responses in return, they must include 
the name of a response queue (that the sender must 
create in advance) in all requests that they make to 
the receiver. 

Turning now to FIG. 2A, shown is a block diagram 

20 illustrating the basics of the transportation of a 

message 75 from message queuing machine 1 (computer 80) 
to machine 2 (computer 90) over a transport network 85 
supporting such network transport protocols as TCP/IP 
or IPX . The message 75 contains self-descriptive 
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objects and/or self-descriptive data elements in 
accordance with the present invention. Each computer 
80 and 90 performs both server and client operations 
for transferring messages 75 between their respective 
5 message queues. 

A message queuing enterprise network can span many 
locations and operate on top of different transport 
network protocols- The topology of the message queuing 
enterprise network can* be described in terms of 

10 (1) physical location and (2) communication protocol 
connectivity. The term "site" describes an aspect of 
the enterprise network based on a physical location. 
In contrast, a "connected network" describes an aspect 
of the message queuing enterprise network according to 

15 communication protocol connectivity. 

An enterprise network is a collection of sites 
connected through slow/expensive network connections. 
A site, is a physical collection of machines, where 
communication between two machines is cheap and fast. 

20 These two computers are typically located in the same 
physical location, although not required. The concept 
of a site is integral to the message routing algorithm 
employed by the message queuing system. In order to 
route messages throughout the message queuing 



enterprise network, a message queuing computer must be 
able to locate the destination message queue. A subset 
of computers within the message queuing network are 
also directory servers ("DS servers") which maintain 
message queuing information, including information to 
enable routing of messages such as sites, connected 
networks, and names of DS servers within the message 
queuing network. 

A MSMQ network is a collection of addresses 
"speaking" several communication protocols and are 
connected by physical communication links. A connected 
network is a collection of addresses, where every two 
addresses can communicate directly (i.e., the 
underlying communication network provides the 
connection if all its components are on-line) . Inside 
a connected network, communication delay and cost may 
vary. The physical communication lines and the traffic 
overhead define the communication delay and cost. Two 
addresses in a connected network may be connected by a 
fast, cheap line, for example, if their machines are in 
the same site or by a slow expensive line if their 
machines are in different sites. Two machines belong 
to the same connected network if they support the same 
protocol, and can have a direct session on that 
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protocol. A machine can support more than one 
connected network on a specific protocol if it supports 
more than one address which belong to different 
connected networks on a specific protocol. A connected 
5 network does not consist of more than one protocol. 
These concepts are further illustrated in 
FIGs. 2B-C, shown in block diagrams illustrating an 
enterprise network 200. As illustrated in FIG 2B, 
shown are three sites: site A (201), site B (202), 

10 site C (203) , connected by network lines 212, 213, and 
223. As previously described herein, sites are a 
grouping of computers within a message queuing network 
grouped together for the purposes of routing. One 
distinction that can be made between sites in a typical 

15 message queuing network is that sites are connected to 
relatively slow, expensive lines. Computers within a 
site are typically connected by fast, cheap lines such 
as those computers residing on a single Ethernet. For 
example, site A (201) contains a plurality of message 

20 queuing computers 230, 231 connected by fast networking 
lines 234. These computers can also perform additional 
message queuing functionality. For example, computer 
231 might be a DS server. In addition, computer 232 
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might be a remote access server (RAS) with software to 
respond to client requests packets. 

Turning now to FIG. 2C, illustrated is an 
enterprise network 200 showing sites A-C (201-203) and 
5 connected networks 261-264. As previously described 

herein, each connected network within a message queuing 
network represents those machines which can directly 
communicate with each other using a single networking 
protocol, such as TCP/IP or IPX. As shown in FIG. 2C, 

10 computers 270-272, 280-282 and 290-291 support TCP/IP 
protocol, and computers 283, 290, 294 support IPX 
protocol. A computer can use more than one protocol as 
represented by computer 290, or support more than one 
network interface for the same protocol as represented 

15 by computers 270 and 280. In addition, a computer can 
be connected to more than one connected network. For 
example, computers 270 and 280 belong to two connected 
IP networks 261 and 262; and computer 290 belongs to 
two connected networks 261 and 264 supporting IP and 

20 IPX protocols. It is also possible for a connected 
network to span all sites, such as illustrated by 
connected network 261 spanning sites A-C (201-203) . 

In one embodiment of the present invention, 
messages are sent as serialized dictionary objects over 
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a message queuing network. The dictionary represents 
an abstract data type defined in terms of four 
fundamental operations that can be performed on it, 
namely: add, remove, lookup, and enumerate; with the 
5 addition of two operations to serialize and unserialize 
the persistent dictionary object to enable the 
dictionary object to be sent across a network. 

Turning now to FIG. 3A, shown is a block diagram 
illustrating persistent dictionary object 300 
10 comprising an IDictionary interface 310 and an 

IPersistDict interface 320. The dictionary object 300 
contains a data structure and methods that when 
invoked, perform operations on the internal data 
structure. The operations performed on the data 
15 elements correspond to methods invoked to perform the 
desired operation. As implied by the method names, 
add ( ) 301^adds a specified element to the dictionary; 
remove ( ) 302 removes a specified element in the 
dictionary;<<Lookup ( ) ^03 finds a specified element in 



20 the dictionary; and enumerate ( ) 3 



mechanism for obtaining the nex^lgmgnt from the 




provides a 



dictionary given a position in the dictionary. To 



enable the dictionary object to be sent across a 



network, the save ( ) method 321 causes the dictionary 
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object to serialize itself to a specified target 



location (i.e., the message body) and the load() method 
322 loads a serialized dictionary object. 

The dictionary elements, in an embodiment of the 
5 present invention, are in the form of a triplet 
comprised of a Name, Type and Value. The Name 



represents a string identifier; the^Type^specif ies the 
type of element which could be as simple as a constant 
or integer, or be a more complex (and very rich) type 

10 such as an Excel spreadsheet or even a serialized data 
dictionary; and the Value specifies a current value or 
state of the element. In an embodiment, the type field 
contains an agreed upon indicator specifying the type 
of element (e.g., 1 is an integer, 2 is a string, 3 is 

15 an object, etc.). In another embodiment, the type 
mechanism is extended to provide a standard way for 
receivers to learn about type indicators that the 
receiver does not recognize such as by querying the 
sending application, the message queuing network, or 

20 some other local or remote process. 

For example, a record of data such as an address 
book entry could be sent as a persistent dictionary 
object, with the address book entries being defined in 
terms of two dictionary elements . The first dictionary 
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element having a Name of "Entry Name", being of Type 
"string", and having a Value of "USPTO"; with the 
second dictionary element having a Name of "City", 
being of Type "string", and having a Value of 
"Washington D.C.". Using Visual Basic and dimensioning 
d as a New PersistentDictionary, the elements could be 

"adde*d"to d using the statements: 

J 



( -^rA'dci^Entry Name" , "USPTO" ) , and 
d.Add("City", " Washington D.C. ") . 
10 Then, the elements could be extracted from d by the 

following references: d( "Entry Name") and d("City"). 

Using the previously described triplet as a data 
element merely illustrates a very generalized abstract 
data element. Various other dictionary data elements 
15 could be employed in keeping with the present 

invention. In addition,^l^t^^inding^techniques could 



be used to make each named element in the data 



dictionary a data member of the object. Using this 
technique, elements of the dictionary could be 
20 referenced directly. For example, a data element 



msword_document in a dictionary d could be referenced 
as d.msword_document as opposed to 
d("msword document") . 



Turning now to FIG 3B, illustrated is a serialized 
dictionary object 360. The first field, CElements 370, 
contains the number of elements in the serialized 
dictionary object 360, which is followed by each of the 
dictionary elements. As shown, the first dictionary 
element 380 comprises the triplet of the Name 381, Type 
382 and Value 383. A dictionary object can contain a 
plurality of dictionary elements as indicated by 
element field 399. 

FIGS. 4A, 5A, 5B, and 4B illustrate the steps 
performed by a sending application, the sending MSMQ 
server, the receiving MSMQ server, and the recipient 
application, respectively, in sending a message object 
from a sending application to a recipient application 
over a MSMQ network in one embodiment. In other 
embodiments, certain of these described functions could 
be performed by the application instead of the message 
queuing network and vice versa. For example, the 
serialization and deserialization of the persistent 
dictionary object could be performed by the sending and 
recipient applications (or by other intermediate 
protocol layers, or by other processes) . In this 
example, the message queuing network would not 
necessarily need to know that it was transporting a 



self-descriptive message. Moreover, self-descriptive 
messages (e.g., persistent dictionary objects) could be 
transported using other network technologies and 
protocols, in addition to, or in place of the message 
queuing network described herein. 

First, turning to FIG. 4A, illustrated are the 
steps performed by a Microsoft Visual Basic application 
preparing and sending a message object containing an 
Excel spreadsheet across a MSMQ network. First, a MSMQ 
queue qr, an Excel spreadsheet xl, and a MSMQ message m 
are dimensioned in steps 405-415 . Next, the body of 
the message m is set to the Excel spreadsheet xl in 
step 420. Finally, in step 425, the MSMQ message in is 
sent via queue q. 

Next, turning to FIG. 5A, the sending MSMQ server 
continues in response to the request to send the 
message object by the sending application in step 420 
(FIG. 4A) . First, in step 505, the message object is 
checked to see if it supports data persistence (such as 
being a COM object) . If it does not support data 
persistence, then the object is not sent in one 
embodiment and processing ends with step 545. In other 
embodiments, it would be possible to add additional 
functionality based on the teachings disclosed herein 
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to incorporate serialization and unserialization of 
arbitrary objects . 

Otherwise, if the message object supports 
persistence as determined in step 505, then the 
5 required size of a buffer is determined and allocated 
in step 510 to accommodate the serialized message 
object. Next, in step 515, the persistent storage type 
supported by the message object is determined. If the 
message object supports streams, then processing flows 

10 to steps 520-525 wherein the message object writes 

itself to the buffer, and the message type is set to a 
"streamed object". Otherwise, the message object 
supports storage (the other storage type for a COM 
object) and processing continues with steps 530-535 

15 wherein a storage pointing to the message buffer is 

created, the object saves itself to the storage (i.e., 
the message buffer) , and the message type is set to a 
"stored object". Finally, in step 540, the MSMQ 
message body is set to the contents of the buffer and 

20 the MSMQ server forwards the message to the destination 
queue . 

When such a message object is received at a 
receiving MSMQ server queue and the message has been 
determined to contain an object by querying the message 



itself using a method of the message, the message is 
processed according to the flow diagram of FIG. 5B. In 
step 555, the object message type is evaluated and if 
it is of a "streamed object" type, then processing 
continues with steps 560-565 wherein the received 
message object creates a stream which is initialized by 
the message buffer memory, and a class identifier 
(CLSID) is obtained from the stream. Otherwise, the 
object message is of a "storage object" type, and steps 
570-575 are performed wherein the received message 
object creates a storage which is initialized by the 
message buffer memory, and a class identifier (CLSID) 
is obtained from the storage. 

Next, in step 580, the OLE interface 
CoCreatelnstance is used to instantiate the message 
object (i.e., the persistent dictionary object). Then, 
the load method 322 (FIG. 3A) of the instantiated 
object is invoked to load the serialized data (from the 
appropriate initialized storage or stream that was 
created in step 560 or 570) in step 585. Finally, in 
step 590, the receiving MSMQ server returns the message 
object (i.e., the instantiated and loaded dictionary 
object) to the recipient application in step 590. 
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The recipient application then uses the received 
self-contained message object as described herein with 
reference to the flow diagram of FIG. 4B. First, in 
step 455, a MSMQ queue q, a MSMQ message m, and a 
5 persistent data dictionary d are dimensioned. Next, in 
step 460, m is set to the message received from the 
sender application via the MSMQ network as explained 
herein with reference to FIGs. 4A, 5A and 5B. Having 
obtained the message m containing the self-descriptive 
10 object, the recipient application processes the message 
however it desires. 

The remaining steps 465-499 illustrate one 
embodiment of such processing. First, if the body of 
the received message is not a persistent dictionary as 
15 determined in step 465, then the non-persistent data 

object (e.g., an integer, record, string) is processed 
by the application. For example, the recipient 
application could print the address book previously 
described herein by setting d to the message body of a 
20 received message containing an address book entry, and 
then using the statement: 

print The d ("Entry Name") is in d("City") 
which would print: 

The USPTO is in Washington D.C. 
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Otherwise, the received message is a persistent 
dictionary as determined in step 465, and d is set to 
the message body in step 470- Next, while there are 
5 elements remaining in the persistent dictionary d, 
steps 477-495 are performed for each element. In 
step 477, an element is enumerated from the data 
dictionary. Next, steps 480-495 are performed which 



embody a case statement switching upon the/ typeof ( )i the 



10 element (i.e., the type of the persistent dictionary 

element received in the MSMQ message) . For example, if 
the type of the element is an Excel spreadsheet, then 
Excel operations are performed. Otherwise, processing 
continues in the case statement with a generic type 

15 "CaseType" provided for illustrative purposes in steps 
490, 495 to signify the diverse and rich types of 
elements that can be sent across a network in a self- 
descriptive message using the present invention. This 
CaseType could be any data type, including an integer, 

20 string, data record, address book entries, or even a 
persistent dictionary. Many different configurations 
are also possible, including the recipient application 
being a CaseType application and processing the 
received element, or a CaseType application being 
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invoked by the recipient application or message queuing 
system to process the received the data element. 

In view of the many possible embodiments to which 
the principles of our invention may be applied, it will 
5 be appreciated that the embodiment described herein 
with respect to the drawing figures is only 
illustrative and should not be taken as limiting the 
scope of the invention. To the contrary, the invention 
as described* herein contemplates all such embodiments 
10 as may come within the scope of the following claims 
and equivalents thereof. 



